Database management system

ABSTRACT

A method of querying a database system, the database system comprising at least one database populated with a plurality of unique, multi-character expressions associated with the data entities of the at least one database, the method comprising: providing a graphical user interface for receiving at least one input selection from a user defining a database query expression; scanning the at least one database with the database query expression to obtain a first set of results; parsing the first set of results with a user profile expression associated with the user to obtain a second set of results, the user profile expression comprising a unique, multi-character expression; and displaying the second set of results in the graphical user interface.

TECHNICAL FIELD

The present invention relates to database systems, in particular to adatabase system which provides an interface database with a hierarchicaltree-like structure using data from a plurality of other databases. Thisdatabase system enables fast and comprehensive data extraction, queryingand output display functions from databases which may be based ondifferent database models.

BACKGROUND

A database model is a theory or specification describing how a databaseis structured and used. A data model is not just a way of structuringdata: it also defines a set of operations that can be performed on thedata such as queries. Several such models have been suggested such asHierarchical model, Network model, Relational model (the most popularmodel), Entity-relationship model, Object-relational model, Multivaluemodel, Object Model and Document model.

As is well known, there is a lack of standardisation of database modelsand systems such that different organisations use different databasemodels or even different departments within an organisation (e.g., theHealth Service) use different database models. Each organisation ordepartment generally chooses the database model considered most suitablefor them or simply accepts the database model recommended to them bytheir IT department or database manager/administrator. Furthermore it isgenerally not possible to manage databases having different databasemodels using one database management system.

Well known database models and systems include those provided byOracle™, Microsoft, Sybase™, IBM™ and the like. Each differ in specificsand typically require an expertise in maintaining and interrogating datawithin their defined data structures.

An innovative database management system that offers considerablebenefits over the relational database model or system referred to abovehas been described in GB 2293697B and GB 2398143B the content of whichis incorporated herein by way of reference. However the use of thedatabase management systems of these GB patents implied that theprevious database models and systems such as the relational databasemodel and system should be simply replaced with the proposed databasesystem. As can be well understood, replacing the databases of an entireorganisation such as a large healthcare provider, or multiple smallerorganisations to use the database system of the GB patents would be noeasy task.

It is an object of the present invention to provide a solution to someor all of the above problems.

SUMMARY

Accordingly, the present teaching provides a database system whichconfigures a database model with a hierarchical tree-like structureusing data from a plurality of databases. The plurality of differentdatabases can each be structured according to a different databasemodels. By providing an intermediary data structure (database) between auser of the databases and the stored data the present teachingrecognises that multi-character expressions can be adapted and used toprovide access to data stored within each of the different databasemodels through use of a single interrogatory syntax.

In accordance with the present teaching the intermediary data structureis provided as a storage model based on a conceptual data model inaccordance with a hierarchical structure. Every entity, every attributeand every entity occurrence within each of the underlying databases isassigned a unique, multi-character expression which defines therelationship between each entity, attribute and entity occurrence withevery other entity, attribute and entity occurrence in the database andmay also uniquely define an attribute value to an occurrence of anentity. The expressions are stored in an expression set table linkingeach element of each expression with a natural language phrase relatingthe expression to a hierarchical level and a position in a data model.The “expressions” used are multi-character expressions convenientlydivided into a number of “words”, each of a number of bytes.

Each multi-character expression indicates a context (in the data model),a specification (e.g. a description/definition of the data beingencoded) and a quality (e.g. actual data values or pointers thereto).Where any of these components are unknown or irrelevant, a wildcardcharacter or “non-deterministic” character can be used. A feature of theexpressions used to describe the data model is that similar datastructures can be replicated throughout the main tree of multi-characterexpressions by changing only selected characters in the expression. Suchan arrangement is similar to that discussed in detail in the patent GB2293667B, and in subsequent related patent GB 2398143B, and as is clearfrom the disclosure of these earlier applications, the use of thesemulti-character expressions to store data in a database offers extremelyfast searching and context switching capability when accessing data fromthe database.

Furthermore, the multi-character expression approach to data storage inintermediary data structure provides a flexible data-driven method ofmanaging access to patient information at the most granular level. Thisis achieved by the present teaching providing access to data by a userwithin the above outlined system via multi-character expression “views”of that data.

In particular, the present teaching provides a method of querying adatabase system, the database system comprising at least one databasepopulated with a plurality of unique, multi-character expressionsassociated with the data entities of the at least one database, themethod comprising: providing a graphical user interface for receiving atleast one user input selection defining a database query expression;scanning the at least one database with the database query expression toobtain a first set of results; parsing the first set of results with auser profile expression associated with the at least one user inputselection to obtain a second set of results, the user profile expressioncomprising a unique, multi-character expression; and displaying thesecond set of results in the graphical user interface.

BRIEF DESCRIPTION OF THE FIGURES

The present invention will now be described by way of example, and withreference to the accompanying drawings in which:

FIG. 1 shows an exemplary database system described in accordance withthe present teaching;

FIG. 2 shows an exemplary data model of the interface database;

FIG. 3 shows an overview of the use of an expression set together withthe implementing tables of the database system of the present teaching;

FIG. 4 shows a log in screen of the GUI in accordance with the presentteachings;

FIG. 5 shows a screen shot of the report manager feature in accordancewith the present teachings;

FIG. 6 shows a screen shot of the group manager feature in accordancewith the present teachings;

FIG. 7 shows a screen shot of the group manager feature wherein the usercan define the scope of a new group in accordance with the presentteachings;

FIG. 8 shows a screen shot of the group manager feature wherein the usercan select the descriptive filters of a new group from a dataset inaccordance with the present teachings;

FIG. 9 shows a screen shot of the group manager feature wherein the usercan choose the descriptive filters of a new group in accordance with thepresent teachings;

FIG. 10 shows a screen shot of the group manager feature wherein theresults of applying the scope and descriptive filters are shown inaccordance with the present teachings;

FIG. 11 shows a screen shot of the group manager feature of FIG. 11wherein a user has selected the “Report on this Group” option inaccordance with the present teachings;

FIG. 12 shows a screen shot of the report manager feature wherein thegroup created with regard to FIGS. 4-11 is selected for reporting on inaccordance with the present teachings;

FIG. 13 shows a diagram showing two different views of data that can beassigned to a user in accordance with the present teachings;

FIG. 14 shows a screen shows a screen shot of the report manager featurewherein “Apply Safe Harbor de-identification” option is selectable

FIG. 15 FIG. 14 shows a screen shows a screen shot of the report managerfeature wherein “Apply Safe Harbor de-identification” option is disabled

FIG. 16 show a profile processor in accordance with the presentteachings.

DETAILED DESCRIPTION

In order to overcome the limitations of the current state of the artthere is provided in the present application a method of operating adatabase system. FIG. 1 depicts such a database system 100. It can beseen that access to a plurality of databases 103 is provided.Furthermore each of the databases 103 can have a structure based on arespective database model. Any conventional database model can be usedfor databases 103 e.g., the above mentioned relational model etc. As iswell known to those skilled in the art each database stores a pluralityof data entities having attributes and occurrences within the structureof the database.

Although a plurality of databases 103 are shown in FIG. 1, a singledatabase 103 can also be used. Furthermore, when using a plurality ofdatabases 103, at least two can differ in their database managementsystem such that each database management system defines a set ofprograms that enable a user to store, modify, and extract informationfrom the respective database.

The database management systems used for the databases 103 can beselected from one or more of those provided by Oracle, FoxPro, IBM DB2,Linter, Microsoft Access, Microsoft SQL Server, MySQL, PostgreSQL andSQLite.

Database system 100 also includes an interface database 102, whereby theinterface database 102 is populated with a plurality of unique,multi-character expressions associated with the data entities of the atleast one database 103. Details of the structure of this interfacedatabase 102 are described in more detail below.

Also shown in FIG. 1 is a graphical user interface (GUI) 101. Thegraphical user interface 101 is configured to effect generation ofdatabase query expressions. It can be understood that one of the mainobjectives of the present teachings is to allow a user to access datastored in the plurality of databases 103 without using the databasemanagement system specific to the plurality of databases 103 but ratherusing the interface database 102 accessed through the graphical userinterface 101. This takes advantage of faster searching and contextswitching capability of the interface database 102 and is a clearadvantage over simply querying the databases 103 directly as will bebecome apparent hereinafter.

In order to achieve the aforementioned objective of the presentteachings—allow a user to access data stored in the plurality ofdatabases 103 using the interface database 102 accessed through thegraphical user interface—then the data stored in the plurality ofdatabases 103 must be converted into unique, multi-character expressionsfor storage in the interface database 102. The details of implementingsuch a conversation can be chosen as appropriate by one skilled in theart. However, one possible implementation involves iteratively accessingdata within the plurality of databases 103 to convert data not alreadyconverted and stored as unique, multi-character expressions in theinterface database 102 to unique, multi-character expressions forstorage in the interface database 103. The frequency of these intervalscan be set by the interface database 102 administrator/manager asappropriate. For example, where data is not frequently altered/updatedin databases 103 then interface database 102 can be updated during quietprocessing times such as during the night. Another possibleimplementation for updating the interface database involves updating theinterface database 102 each time data on one of the plurality ofdatabases 103 is updated such that the interface database 102 is updatedon a determination that one of the plurality of databases 103 has beenupdated. However, where one or more of databases 103 exists in a highvolume data changing/altering environment then this can place anundesirable load on the processing resources of the interface database102. It can also be understood that maintaining the plurality ofdatabases 103 can occur concurrently with maintenance of the interfacedatabase 102.

Furthermore, the plurality of databases 103 and the interface database102 do not have to be provided at the same geographical location andusually such that at least one of the databases 103 and interfacedatabase 102 can be provided as a cloud database.

Turning to a more detailed discussion of the structure of the interfacedatabase 102, a plurality of unique, multi-character expressions aredefined by assigning to every entity, every attribute and every entityoccurrence a unique, multi-character expression, the expression having apredetermined hierarchical structure which defines the relationshipbetween each entity, attribute and entity occurrence with every otherentity, attribute and entity occurrence in the second database.

The way in which the database structure of the interface database 102 isimposed by the assignment of these expressions is best described withreference to an exemplary data model as shown in FIG. 2.

The tree structure in FIG. 2 represents the complete data model. Eachhierarchical level of the data model is shown horizontally across thetree structure, and each one of these hierarchical levels may berepresented by an appropriate byte I₁, to I₁₅ of the expression shownvertically on the left hand side of the drawing. It will be understoodthat the number of bytes representing a character in the expression, orthe length of the overall expression, can be varied according to therequirements of a particular system. At the highest level of the treeI₁, context information is shown defining the organisation from whichthe data was provided, for example the National Health Service (NHS),Prison Service, Local Authority, Educational Establishment etc.

It can be understood that the data for constructing the interfacedatabase 102 is provided from respective databases for each of theNational Health Service (NHS), Prison Service, Local Authority, andEducational Establishment. In particular, it should be understood thateach of these organisation uses at least one database corresponding tothe databases 103 of FIG. 1. However, it should also be understood thatthe database system 100 can be directed to one of these organisationse.g., National Health Service (NHS) such that at the highest level ofthe tree I₁, context information is shown defining the department orsection of the NHS from which the data was provided.

As outlined above, the first byte I₁ in every multi-level expression todesignate the organisation or database installation from which data isbeing imported. This enables simple use of filters and masks relating tothis byte, for example to prevent or enable one organisation queryingthe receiving database from viewing data belonging to anotherorganisation etc. Obviously, once data has been collated in theinterface database 103 from the plurality of databases 103 access toportions of the imported data must be limited. For example, a user ofthe interface database 103 should not be able access all the data acrossmultiple organisations. In particular, a user of the interface database103 who is only permitted to query or access files related to the healthservice will have the first byte I₁ restricted to that used by thehealth service. Therefore, any query that the user makes is limited toonly the health service i.e., only data of the health service issearched. Further restrictions can be placed on the user by restrictingother bytes further down on the multi-character expression such that auser is restricted to queries within departments of an organisation.Ensuring information security and user authorization is particularlyrelevant when dealing with medical records of individuals. For example,the The Health Insurance Portability and Accountability Act of 1996placed particular importance on the privacy of individuals' medicalrecords. The inventors of the present application have found that thedatabase system described herein has broad ranging applications in themedical/healthcare field and ensuring that private health information(PHI) is secure is tantamount. As more comprehensive approach toensuring security of PHI is discussed in detail with regard tables 1 and2 as well as FIG. 13.

The significance of byte I₂ is discussed in more detail in GB 2293697Band GB 2398143B, but broadly speaking indicates a data type from aplurality of possible data types that might be used.

Within each organisation (e.g. the Health Service or healthadministration organisation) there may typically be a number ofdepartments or functions or data view types (represented by byte I₃)such as administration, finance/accounts and clinical staff, all of whomhave different data requirements. These different data requirementsinclude:

a) different data structures or models pertaining to differentorganisational hierarchies within the department;

b) different views of the same entities and occurrences of entities; and

c) the same or different views of “standard format” data relating todifferent occurrences of similar or identical entities or attributes.

The interface database 102 must be able to accommodate these differencesin the underlying organisations/departments and their correspondingdatabases. The significance of this to the present teaching will becomeclear as one progresses downward through the hierarchy.

Each department may wish to segregate activities (e.g. for the purposeof data collection and analysis) to various regional parts of theorganisation: e.g. a geographically administered area or asub-department. This can be reflected in the structure of the seconddatabase 102 by expression byte I₄. Each geographically administeredarea may further be characterized by a number of individual unit types,such as: (i) hospitals, health centres etc. in the case of an a healthservice application; (ii) schools or higher education institutions inthe case of an education application; (iii) prisons and remand centresin the case of the prison service application.

Each of the organisations and units above will have different datastructure requirements (as in (a) above) reflecting different entities,attributes and entity relationships within the organisation and theseare provided for by suitable allocation of codes within the I₆ to I₁₀range of expression bytes. In this case, the same alphanumeric codes inbytes I₆ to I₁₀ will have different meaning when in a branch of the treeunder for example a structure such as that provided by the NationalHealth Service (NHS) in the UK, than when under, e.g. the educationbranch, even though they exist at the same hierarchical level. As anexample, the sub-tree structure represented by particular values ofbytes I₆ to I₁₀ may refer to patient treatment records in the NHScontext, whereas those values of codes may refer to pupil academicrecords in the education context.

However, in the case of (b) above, where the organisational unitrequires the same or different views of the same entities, attributesand occurrences of entities as other organisational units, the codes inbytes I₆ to I₁₀ of one branch of the tree will represent the sameunderlying structure and have the same meaning as corresponding bytevalues under another branch of the tree. An example of this is whereboth the administration departments and the finance departments requirea view of the personal details of the staff in the hospital, bothdoctors and nurses. Note that the views of the data may be the same ordifferent for each department, because the view specification isinferred from the higher level I₁ to I₅ fields. In this case, forentities, attributes and occurrences of entities which are the same ineach sub-branch, some or all of the codes I₁ to I₅ which identify eachentity occurrence will have identical values.

In the case of (c) above, i.e. the same or different views of standardformat data relating to different occurrences of similar or identicalentities and their attributes, it will be understood that a number ofpredefined bytes require the same specification regardless of theparticular organisation using them. For example, a sub-tree relating topersonnel records, and including a standard format data structure forrecording personnel names, addresses, National Insurance numbers, sex,date of birth, nationality etc. can be replicated for each branch of thetree in which it is required. For example, all of the organisations inthe tree will probably require such an employee data sub-tree, and thusby use of standardised codes in bytes I₆ to I₁₀ such organisationalsub-trees are effectively copied into different parts of the tree.However, in this case, the context information in fields I₁ to I₁₅ willindicate that within each organisation, we are actually dealing withdifferent occurrences of similar format data.

The tree structure defined by the expressions I₁ to I₁₅ can be used todefine not only all entity types, all entity attribute types and allentity occurrences, but can also be used to encode the actual attributevalues of each entity occurrence where such values are limited to adiscrete number of possible values. For example, in the sub-treerelating to treatments in the hospital context, “drug” is an entitywhich has a relation with or is an attribute of, for example: doctors(from the point of view of treatments prescribed); patients (from thepoint of view of treatments given); administration (from the point ofview of maintaining stocks of drugs) and so on. The entire set of drugsused can be provided for with an expression to identify each drug. In anillustrative embodiment, the parts of the expression specific to theoccurrences of each drug will be located in the I₁ to I₁₅ fields asshown in FIG. 2. Thus when used in conjunction with the appropriatefields I₁ to I₁₀ it will be apparent whether the specified drug is inthe context of a treatment prescribed by a doctor, a treatment receivedby a patient, or a stock to be held in the hospital pharmacy.

Further bytes in the expression, lower in the hierarchy can beassociated with the drug to describe, for example, quantities orstandard prescription types. It will be apparent whether the expressionrefers to a prescribed quantity or a stock quantity by reference to thecontext information found higher in the hierarchy. In practice, thenumber of discrete values allowed for each of these grouped “entityvalues” using the five fields I₁ to I₁₅ is approximately 200⁵=32×10¹¹.The number of permutations allowed can actually be expandedindefinitely, but in practice this has not been found to be necessary.It is noted, however, that the described model of FIG. 2 merelyillustrates a principle of the data model. In an alternatively preferredembodiment, twenty-character expressions are used and the semanticsignificance of specific fields therein (I₁ to I₂₀) may differsignificantly from those presently described in connection with FIG. 2.For example, in the alternative preferred model, “entity values” canoccupy each of the two-byte elements I₁₃ to I₂₀, thereby allowing 65536⁸discrete values (=3.4×10₃₈).

Thus, in the fifteen character expression I₁ to I₁₅, each characterrepresents a natural language expression (e.g., English languageexpression) defining some aspect of the data model, and by travellingdownward through the table it is possible to compose a collection ofnatural language expressions which represents the complete specificationof an entity, an attribute or an entity occurrence.

Although FIG. 2 has been described with reference to the highest levelof the tree I₁ being the NHS, prison service, local authority etc., andthe present teachings should not be construed as being limited to such aconfiguration. As previously mentioned the inventors of the presentapplication have found that the database system described herein hasbroad ranging applications in the medical field and particularly inbuilding a new kind of healthcare analytic software. Therefore, the toplevel of the tree could easily be a plurality of individual hospitals,health centres while the lower levels of the tree could be individualdepartments within the hospital such as oncology, orthopaedics etc. Itis readily apparent that a number of other configurations are possiblesuch as the top level of the tree representing individual departmentswithin a single hospital or health centre.

Referring again to FIG. 1, the interface database 102 is also configuredto store said multi-character expressions in an expression set tablelinking each element of each expression with a natural language phraserelating the expression to a hierarchical level and a position in a datamodel.

An overview of the use of an expression set together with theimplementing tables which comprise an illustrative embodiment of thedatabase system of the present invention is now described with referenceto FIG. 3.

Every occurrence of an entity about which information must be stored isrecorded in the entity details table 510. Each occurrence of each entityis given a unique identifier 512 which is assigned to that entityoccurrence, and information about the entity is stored as a valueexpression information string 513. Examples of value expressions are thecharacter strings giving names, street addresses, town, county, countryetc., or drug name, manufacturer's product code etc. These details areessentially alphanumeric strings which themselves contain no furtheruseful hierarchical information and are treated solely as characterstrings.

The unique identifier 512 of each entity occurrence in the entitydetails table 510 provides a link to an entity history table 520 whereentry of, or update to the entity occurrence status is stored. In thistable, the event updating the database is given a date and/or time 524,an expression 526, and the unique identifier 522 to which the recordpertains, and may include other information such as the user ID 527 ofthe person making the change.

In the entity history table 520, various details of the event beingrecorded may not be available, or may have no relevance at that time.For example, a new patient in a designated hospital may be admitted, andsome details put on record, but the patient is not assigned to anyparticular doctor or ward until a later time. Additionally, someinformation may be recorded which is completely independent of the userview or other context information. Thus the event is logged with onlyrelevant bytes of the expression encoded. Bytes for which theinformation is not known, or which are irrelevant to the event arenon-deterministic and are filled with the wild card character, “#”.

The entity history table 520 may also include an event tag field 528which can be used in conjunction with a corresponding field in anepisode management table to be described hereinafter. It will indicatewhich coding activity was being carried out when the expression wasassigned to the entity. For example, this tag could indicate whether thecoding was carried out during an initial assessment, an update, acorrection, a re-assessment, etc. This tag also orders entity codes intoevent groups. For example, in the medical context, when a person entersthe system as a patient, they initiate an admission. An episode can havemany spells, (such as a period of treatment on ward A, followed by aperiod on Ward B) and a spell can consist of many events (such ascontacts with the attending physician, procedures, tests). What is more,a patient can be involved with more than one episode at a time (forexample out-patient episodes with different hospitals pertaining todifferent illnesses), and under each episode, more than one spell at atime (e.g. involvement with more than one department of each hospital,each dealing with different aspects of each illness). Many organisationsneed to store this sort of information for costing and auditingpurposes. By coding this information into an expression, it will bepossible to browse this information.

The entity history table may also include a link field 529 which isdesignated to link related groups of codes allocated during a particularentity-event-times. For example, in a social services application, ahome visit, a visit date, miles travelled and the visitor could all havean expression associated with the visit event. The link field will linkthese expressions together. Alternatively, the event tag field may alsocater for this function.

A memo field 523 may also be included in the entity history table toallow the user to enter a free text memorandum of any length for eachcode allocated to an entity. In effect, every time a field is filled, amemo can be added.

The expression set of the entire database is recorded in a third table,the expression set table 530. This encodes each expression against itsnatural language meaning, and effectively records the data model asdefined by the hierarchical structure of FIG. 2. There is a naturallanguage meaning for each byte of the expression, each byte representinga node position in the data model tree, and the precise significance ofevery occurrence of every entity or attribute is provided byconcatenating all natural language meanings for each byte of theexpression: e.g. and again in the context of the NHS in the UnitedKingdom,-Presentation Data Type—Administrator's View—Region1—HospitalNo2—Doctor Record—Name—DoctorID1.

The expressions may include expression extensions which map a sub-treeonto the main tree as are discussed in more detail in aforementioned GB2293697B and GB 2398143B. For convenience, these extension expressionscan be located within the expression set table 530 (the extensionentries being identified by the byte I₁, or could be located in asupplementary table (not shown), in which the pointer fields I₁₁ to I₁₅of the main expression are used as the first fields I₁ to I₅ of theextension expression.

The entity history table 520 and the expression set table 530 may eachinclude an extra field holding a version code. In the entity historytable, this would indicate a version number of the expression in use atthe time the record was created; in the expression set table,expressions may be varied over time according to the version code given.This allows the structure of the hierarchy to change over time withoutnecessarily introducing new expressions. This assists in maintainingbackward compatibility of recorded data.

In use, the database management system first constructs the data modeltree structure in the expression set table 530, with each expressionbeing allocated a corresponding natural language term. This can be doneby dialogue with the user, or by systems analysis by an expert.Preferably, pre-formatted codes representing certain data structures areused or useable by many different users. For example, personnel filetype structures may be used by many different organisations. This allowscompatibility of databases to allow data sharing between organisations,with users being allocated blocks of codes for their own user-specificpurposes, as well as using shared codes which have already been definedby a higher authority.

In constructing the table, for implementation reasons discussed later,it is highly desirable that the table is maintained in strictalphanumeric order of expressions, with discontinuities between higherand lower tree branches filled in with blank specification lines. Itwill be understood that these correspond to particular levels within thetree structure for which there are no divisions of branches.

Additional fields may be included in the expression set table. Forexample, a note flag field 532 may be used to signify that explanatoryinformation is available for a term. This would typically provide apointer to a notes table. A symbol in this field could indicate theexistence of, for example, passive notes (information available onrequest); advisory notes (displayed when the code is used); andselection notes (displayed to the user instead of the natural languageterm). A sub-set field 533 may also be provided for expressionmaintenance tasks, but these are not discussed further here.

When an expression set table has been constructed, it can be related toindividual entity occurrences in the following manner. As previouslydiscussed, the unique occurrences of entities can be placed in theentity details table 510, each having a unique identifier 512. This islinked to the expression set table, and thus to the tree via the entityhistory table. This records the entity unique identifier 512 in a column522 and links this with the appropriate expression or part expression526. The date of the event is logged in field 524, and other details maybe provided—e.g. whether the data entry is a first registration of arecord, whether it is a response record (e.g. updating the database)etc.

Other tables may be used beyond those described in connection with FIG.2, or the tables structured differently. In one embodiment, theexpression set in table 530 is used to identify entities and attributesof entities, together with individual occurrences of entities that donot change over time. Details of occurrences of entities that aretransient to the data model may be recorded in a separate table, such asthe entity history table 520. Such transient objects may be, forexample, individual personnel whose existence in the data model isimpermanent or whose function (place) within the data model may changeover time (e.g. by promotion of staff or transfer within theorganisation). In this instance, the unique identifier 522 and date/timefield 524 relative to the expression field 526 indicate the function ofthat entity occurrence at that time.

The entity ID table 550 (FIG. 2) is an example of a secondary tablewhich is used when communicating and sharing data with other systems.This table matches the entity unique identifier ID codes with entity IDcodes used by other systems.

It is also possible to record static entity details in a form which isstructured ready for input and output. For example, name, address andtelephone records may be stored in successive columns of an addresstable 560, each record cross-referenced to the main data structure bythe expression code or cross-referenced to an entity by the expressioncode I₁ to I₁₅. The link can thus be made with either the expression settable 530 or the entity history table 520. Then, whenever that branch ofthe tree is accessed pertaining to one individual record, the fullstatic and demographic details of that entity occurrence may be accessedfrom a single table.

A similar arrangement is shown for providing detailed drug information,by drug table 570.

A further modification may be made to the embodiments described above inrespect of the use of the entity details table 510. It is not essentialfor all information about an entity occurrence to reside in the entitydetails table 510.

In some models, it is advantageous to restrict the use of the entitydetails table 510 to that of a “major entity” only-the most significantentity forming part of the modelled organisation. For example, in thehospital environment, the patient could be chosen as the major entity.In this case, all other (non-structural, character-string) informationabout entities can be located in an appropriate field of either theentity history table 520, or the expression set table 530. In the caseof the entity history table 520, an appropriate field to use is the memofield 523, and in the case of the expression set table 530, anappropriate field to use is the natural language term field 535. It willthus be understood that, where the non-structural information held abouteven the major entity is small, the entity details table 510 can bedispensed with all together.

As can be seen from FIG. 1, the database system 100 also includes agraphical user interface 101, the graphical user interface 101 beingconfigured to receiving a user selection defining a database queryexpression, the database query expressions being parsed only against theinterface database 102 to affect a return of data reflective of the dataquery expressions.

A database system provided in accordance with the present teachingoffers significant advantages in the execution of database queryingfunctions as hereinafter described. In particular, the present teachingsoffer advantages in reporting and database querying particularly forusers have different respective assigned roles as will be explained inmore detail herein.

To create a query, the database system defines a query expressioncomprising fifteen bytes (I₁ to I₁₅) which correspond with theexpressions as stored in the entity history table 520 and expression settable 530. The query expression will include a number of deterministicbytes and a number of non-deterministic bytes. The non-deterministicbytes are effectively defined as the wild-card character “#”—“matchesanything”. The deterministic bytes are defined by the query parameters.

For example, a simple query might be: “How many patients are presentlyregistered at hospital X”. To answer this query, the query expressionimposes deterministic characters in fields I₁, (=NHS), I₄ (=hospitalidentity), I₆ (=patients). Other context information may be imposed byplacing deterministic characters in bytes I₂ (=presentationinformation). All other bytes are non-deterministic and are set to “#”.The database scans through the expression set table matching thedeterministic characters and ignoring others. It should be noted that inthe preferred embodiment, the expression set table is maintained instrict alphanumeric sequence and thus very rapid homing in on thecorrect portions of the database table is provided where high-orderbytes are specified. This will normally be the case, since thehierarchical nature of the expression set will be arranged to reflectthe needs of the organisation from which the data was retrieved. Thedatabase system can then readily identify all the tuples of theexpression set table providing a match to the query expression.

A significant advantage of the database structure will now becomeevident. The answer to the initial query has effectively homed in on oneor more discrete portions of the expression set table and counted thenumber of tuples matching the query expression. Supposing that the usernow requires to “progressively query” by stipulating additionalconditions: “How many of those patients are being prescribed drug Y”requires only the substitution of the non-deterministic character “#”with the appropriate character in the requisite field In of theexpression to change the result. Similarly, carrying out statisticalanalysis of other parameters, such as: “How many patients were treatedby doctor Z with drug Y” can rapidly be assessed. It should beunderstood that progressively narrowing the query will eventually resultin all bytes of the query expression becoming deterministic and yieldingno match, or yielding a single patient entity match whose details canthen be determined by reference to the entity details table 510 (or theappropriate memo field).

It should now be clear that the key to the speed of result of thestatistical querying function is the construction of the expression settable. When imposing conditions on various attributes of an entity, i.e.by setting a deterministic character in a byte of the query expression,the relevant data will be found in portions of the table in blockscorresponding to that character. Progressive querying requires onlyscanning portions of the table already identified by the previouslyquery. Even where a higher level context switch takes place, relevantparts of the expression set table can be accessed rapidly as they appearin blocks which are sequenced by the expression hierarchy.

Scanning the table can be achieved most efficiently by recognising thatonly the highest order, deterministic byte of the query expression needbe compared with corresponding bytes of each record in the expressionset table until a first match is obtained. Thereafter, the next highestorder byte must be included, and so on until all deterministic bytes arecompared. This results from maintaining a strict alphanumeric orderingto the table.

Another type of querying relates to examining the historical aspects ofthe database through the use of entity history table 520. For example,the query may be, “In the last year, what drugs and quantities have beenprescribed by doctor X”? To answer this query, the query expression isformulated in the same manner as before with regard to the expressionset table 530, imposing deterministic bytes in the appropriate places inthe query expression. This will include one or more “lowest order” bytesin I₁₁ to I₁₅ which actually identify a doctor, and non-deterministiccharacters against the drug fields. This time, however, the entityhistory table 520 is scanned, in a similar manner, seeking only matchesof deterministic characters. In a preferred embodiment, the entityhistory table 520 will be maintained in chronological sequence and thusthe search can be limited to a portion of the table where datelimitations are known and relevant. Matches of deterministic characterswill be found throughout the table where a relevant event relating toprescription of a drug by doctor X is found. Note that the entityhistory table 520 may include other fields which can be used to imposeconditions on the query, such as the user ID of the person entering therecord.

A further type of querying relates to analysis of the records pertainingto a single entity value: the entire medical record of patient X. In thepreferred embodiment, patient X would be identifiable from the entitydetails table 510.

The query would initially involve searching for the patient's name tolocate the unique identifier (unless that was already known). Once theunique identifier for a patient was known, then the entire entityhistory table can be scanned very rapidly for any entry including theunique identifier. The strengths of the present invention will then berealized in that the output from this scan will provide a number ofentries each of which carries all of the relevant information about thatpatient incorporated into the extracted expression bytes I₁ to I₁₅. Theentire patient's record can then be “progressively queried” withoutrecourse to any further searching operation on the main entity historytable 530. Specific details of the patient's treatments, doctors,hospital admissions, prescriptions etc. are all very rapidly availableat will be assertion of appropriate deterministic bytes in theexpression I₁ to I₁₅.

It is noted that the event history table will include many records wherethe expression stored in the record contains many non-deterministicbytes. For example, where a doctor X prescribes a patient Y with drug Z,other bytes of the expression may be either not known, or not relevant.For example, the patient may have been assigned to a ward W in thehospital which could be identified by another byte. However, this venuein which the treatment took place might be: a) unknown; b) known but notrelevant to the record; or c) automatically inferable from the contextof the person making the record entry. Whether this information isincluded in the record is stipulated by the users; however, it will benoted that it does not affect the result of the query whether the bytein the entity history table relating to WARD W is deterministic ornon-deterministic, because the query expression will set that relevantbyte to non-deterministic unless it is stipulated as part of the query.

When the database system has extracted all of the records of the entityhistory table matching the query expression, it preferably saves theseto a results table for further querying, or progressive browsing. Forexample, the results table can then be analysed to identify whichtreatments were made at an individual hospital or by an individualdoctor by setting additional conditions on particular bytes of the queryexpression. Memo fields can be extracted to view comments made at thetime of treatment. It can be seen that the results table formed inresponse to the initial query actually contains all of the informationrelevant to a given patient's treatment, and not just the answer to theinitial query “What drugs have been prescribed to patient X”?

In summary, the information of the database is stored in such a mannerthat data for a query may be extracted far more rapidly than relationaldatabase storage schemas such as those used in databases 103, and withan expression for each extracted record. The presence of this expressionin the query result has an important effect. A unique reporting benefitgained is the scope for progressive querying and “interactivereporting”.

When a database query is executed to provide information for a report,the answer will be made up of a number of expression records. Thissubset of expressions inherits all the structural information held inthe main expression set.

It should be noted that in the above exemplary embodiments if a query isdirected to historical aspects then the scanning is performed on theentity history table 520 but if the query is related to the present suchas “How many patients are presently registered at hospital X” thenexpression set table 530 is scanned. As can be understood from theabove, the expression set table 530 is used for referring to the logical“current state” of an entity (e.g., patient) and the entity historytable 520 for referring to the logical “history state” of an entity.Although these tables are described above as separate tables, thepresent teachings are not limited to such a configuration. The inventorsof the present application have found that these tables (entity historytable 520 and expression set table 530) can easily be merged into asingle table, with a flag indicating a “current state” or “historystate”. As can be appreciated, any scanning of this merged table willresult in a results which has information on both the current state andhistory state of entities.

The ability to perform complex queries and sub queries in the previouslydescribed database system is best utilised through the use of agraphical user interface (GUI) such as that shown in FIG. 1 at 101. Itwill be understood that the present database system provides such a userinterface that is useable to create a database query expression forscanning the interface database 103. To create the query expression theGUI presents at least one user selectable criterion to a user. Thisgenerated database query expression is then used to scan the interfacedatabase 102 (specifically the expression set table/entity history tableor merged table) as outlined above. This use of GUIs to create adatabase query expression and the subsequent results of scanning theinterface database with this expression is described with reference toFIGS. 5-13.

FIG. 4 shows a typical login screen 400 presented to a user of the GUI.If a user enters the correct credentials in appropriate edit boxes (username 401 and password 402 in this case) at the login screen of the GUIthen access to the database system is allowed. As is well known to thoseskilled in the art, “logging in” allows individual access to thecomputer system to be controlled by identifying and authenticating theuser through the credentials presented by the user. Furthermore, as thedatabase system of the subject application is primarily intended for usewith medical records of patients, ensuring that access to these recordsis restricted to only appropriate personnel is of the utmost importance.

Once the user is allowed access to the database system after clickingthe “log in” button 403, the user is presented with a report creationscreen 501 such as that shown in FIG. 5. From this screen the user cancreate new reports (i.e., scan the database using a query expression(s))by selecting the “Create New Report” icon 502. Alternatively the usercan view previously created reports such as the “All Visits 2012” report503 or the “All encounters—Dr Brooker” report 504. Furthermore, thesystem can be set up such that these reports are run periodically. Ascan be appreciated this is quite useful for healthcare practitioners oradministrative personnel as it allows regular monitoring/reporting usinga specific database query expression corresponding to selected criteria.It will be appreciated from the following explanations and descriptionthat although the term “report” is used, the report of the presentteaching is quite different to what is conventionally understood in theart.

For the purposes of the present example, the use of the group manager isof most relevance. Selection by a user of the “Group Manager” icon 605at the top of the screen takes the user to the Group Management andGroup Creation screen 600 which in this arrangement is accessible from atabbed screen change feature of the GUI as shown in FIG. 6. In thisfigure, the user is presented with a plurality (in this example 8) ofpreviously created groups but it should be understood that if a grouphas not been previously created the list of groups is left blank. Inorder to create a new group definition (i.e., perform a scan of thedatabase using a database query expression to return specific patients)the user selects the “Create New Group Definition” icon 606 at the topright of the screen.

The creation of a new group definition is enabled by a dedicatedinterface 700 which is generated in response to activation of the“Create New Group Definition” icon 606. An example of how this will lookto the user is shown in the screenshots of FIGS. 7 a and 7 b (these twofigures appearing on one screen when presented to a user), in whichselection of a plurality of criteria for use in creating the databasequery expression is made. Specifically a graphical user interface suchas that provided by the arrangement of FIG. 7 allows the user to definescope filters 705 to include patients from all hospitals or individualhospitals, a selected doctor or all doctors 710 and a chosen time frame715. It will be appreciated that the specifics of these scope filters isparticular to the example being described and other types of scopefilters could be readily defined and used as part of a differentapplication. The scope filters are defined to present a user withdisplayed user selectable criteria in the form of drop down lists, iconsand tick boxes. It should be appreciated that a user does not have tomake a selection for each of the criteria or the user may simply bepresented with a single criterion such as “Hospital”. As can be wellappreciated by those skilled in the art the selection of each criterionis equivalent to setting deterministic/non-deterministic bytes in thedatabase query expression previously described. The significance of thescope filter is that it enables a user to specify relationships betweenregistered entities (in the example given a patient seen by Doctor X athospital Y).

The new group being created can also be given a name (usually adescriptive name) by the user in the Group Tracker section on the topright of FIG. 7 a—in this case, the name “Emergency Admissions” is givento the group being created and will be visible as an icon 720 to theuser.

The Group Tracker feature of the GUI is particularly useful and is madepossible through the use of the aforementioned results tables. As eachcriterion is selected or updated, a scan is performed using the createddatabase query expression and the results are stored in a results table.The use of the results table enables visual display to the user of theresults so far and thus enables the user to visually identify thoseportions of the data of particular interest for further investigation.In this way the screen 700 is dynamically updated with informationparticular to the search query being constructed during the construct ofthe query. Furthermore, the user may find that the information presentedin the Group Tracker is sufficient for their needs at that time anddecide that there is no need to run a report in order to get the resultsof the query as results are presented in an on-going basis. For examplein the screen shot of FIG. 7, the user is presented with informationthat there are 406 elements associated with the consultant Bankin in theEmergency department for the time period specified, after the Jan. 1,2013. The inventors have found that the Group Tracker is best createdfrom an in-memory representation of the results table. Although theGroup Tracker can be implemented directly against the results table, inpractice using an in-memory representation has led to performanceoptimisation.

The feature of “Filter by date” as shown in FIG. 7 b allows a query tobe performed around a specified target time frame or “width of now” ΔT.A plurality of options 725 are presented to the user in the screen ofFIG. 7 b as indicated by the tabs “Before”, “After”, “Relative” and“Between” wherein the “After” is the tab chosen in the screen of FIG. 7b. Furthermore the filtering by date is not limited to visits thatoccurred after a certain date but by selecting the tick boxes aplurality of further options are presented to the user such as “Startedbut did not finish” etc with reference to the selected date (in thiscase Jan. 1, 2013). Filtering by date in the group manager achieves theeffect of identifying all individuals who had the relevant objectrelationships, events and characteristics within the selected timeframe.

Further criteria can be selected by the user clicking on the“Descriptive Filters” tab 730 of FIG. 7 a, which leads to the displaysuch as that shown in the screenshot 800 of FIG. 8. The screen shown inFIG. 8 provides the user with an interface that allows the user toselect criteria for the descriptive filters by clicking on the “Selectitem from a dataset” option, which in turn leads to display such as thescreenshot 900 of FIG. 9 which provides a plurality of user selectablecriteria 901. As illustrated in FIG. 9, a user is allowed to define thegender, diagnoses, medications, length of stay and charges. Thepreviously mentioned scope filters contrasts with these ‘descriptivefilters’ as the descriptive filters essentially permit the assignmentand searching by attributes of entities such as doctor at hospital shownin FIG. 7 or gender of patient etc. In this way the descriptive filtersprovide a more granular filter definition than that provided by thescope filters. In the exemplary embodiment shown in the GUIs theattributes are patient attributes but they could equally be hospital ordoctor attributes. Furthermore, the criteria 901 presented in FIG. 9 aremerely examples and any of a plurality of other descriptive criteriathat would be useful to the user can be added to the GUI forpresentation to the user. Again, it will be appreciated that selectionof each criterion in FIG. 9 is equivalent to settingdeterministic/non-deterministic bytes of the database query expression.Once the user has chosen the desired descriptive filters in FIG. 9, theuser can select “Include Criteria” or “Exclude Criteria”. For example,the user can choose to include all genders equal to male or exclude allgenders equal to male from the “Emergency Admissions” group. In thepresented example, the user selects “Include Criteria” and is presentedwith the screen of FIG. 10.

FIG. 10 shows the specific descriptive filters chosen by the user inFIG. 9 as well as an updated “Group Tracker” showing each of thedescriptive filters applied to the initial size i.e., the initial groupand the effect that each criteria has on the initial size. As previouslymentioned the user may choose not to run a report on the created group“Emergency admissions” as the number of patients that meet the selectedcriteria (scope and descriptive filters) is presented in the “GroupTracker” section 720-128 patients in the present example.

If the user wishes to run a report then the “Report on this Group” dropdown list is selected and a report type is chosen from the plurality ofreport types “All the Answers”, “Trends”, “Utilisation & Financial”,“Group Count”, “Visits Re-visited” and “Encounter Records”. This isillustrated in the exemplary screen shot 1200 of a graphical userinterface shown in FIGS. 11 a and 11 b 1(these two figuresconventionally appearing on one screen when presented to a user). Inthis case the user selects “Visits Re-visited” and is presented with areport manager interface 1200 for reporting on the selected group“Emergency Admissions” as illustrated in FIG. 12. A number of otheroptions such as “Compare with” are also presented to the user in FIG.12, which allows a user to run a report comparing one group to another.

As previously mentioned, ensuring information security and userauthorization is particularly important when dealing with medicalrecords of individuals. For example, referring again to FIG. 1, if eachof the databases 103 is a database for an individual hospital or medicalcenter then potentially a user at GUI has access to all the medicalrecords of every patient ever treated at any of the hospitals/medicalsystems corresponding to databases 103. Clearly, there is a need forrestriction of the data available to users in the interests of privacyand security.

Accordingly the present teachings offer a multi-level approach toaddress this issue. In addition to standard role and group-basedpermissions, the multi-character expression approach to data storageprovides a flexible data-driven method of managing access to patientinformation at the most granular level.

Access to data by a user at GUI 101 within the above outlined system isvia multi-character expression “views” of that data.

For example, with reference to FIG. 13, a plurality of different datatypes 1-6 are shown at 1302. These data types 1302 are make up acomplete patient record. Assuming that data type 4 is “diagnosis” andAlice has been assigned View B 1303, then Alice is authorized to viewthe restricted data “diagnosis”. On the other hand, Bob has beenassigned view A 1301 and is therefore not authorized to view restrictedinformation “diagnosis”. When viewing a patient record at GUI 101. Allaccess to this data is via these views so at no point is the restricteddata “diagnosis” available to Bob.

Information displayed in the GUI 101 is anonymous by default. Forexample, with reference to previously described FIGS. 4-12, although auser created a group and/or a report, the user does not know theidentity of any of the patients in the group. In FIG. 13, identity datawould be items 7-10 (not shown), so they do not appear in either view Aor view B. Groups are selected using the user's selection from view A orB, so at no point is the identity data available to the user.

The only view that does contain identity fields is only availablethrough an “Identity Check” report. Only the Identity Check report hasaccess to identifying data and the use of this application is configuredvia role & group permissions—only authorized individuals have access.The Identify Check report feature is not described in detail in thesubject application but could be accessed through the report manager forexample, by selecting the Create New Report icon 502 in FIG. 5.

As will be explained further, the present teachings provide a flexiblesecurity system that allows permissions to be set on roles which arethen assigned to users. This allows the creation of roles to representprojects, groups, or just related staff members that should sharecertain permissions. For example, this allow protected healthinformation (or other types of sensitive data) to be restricted tocertain roles, whether a user can create or view a certain kind ofreport, or even the minimum group count to be able to view a report.

Roles are created and managed via the GUI 101. For data protectionpurposes, a user is able to select which role they wish to use whenlogging in, which allows them to create and view reports without anyexposure to protected health information. Although not shown in thefigures, a screen is optionally presented to the user between thescreens of FIGS. 4 and 5 where the user selects a role from the rolesavailable to them. This role selection screen step is not displayed ifthe user has only one role.

Every role has an optional associated “base group” definition which actsas the basis for all groups created under that role. This base group canhave any criteria selectable through the Group Manager. For example, agroup set up for a “Memorial Hospital” role could be restricting reportsto only those patients with a visit at that hospital. This is selectedwhen the role is created. The base group is selected by theadministrator from an existing group definition created in the usualway.

It should be noted that the scoping of roles permits not just thescoping of the people to be reported upon and the datasets to bereported upon but also a much more granular restriction on the scope ofthose datasets. For example, a user could define:

Base group=Males, admitted to hospital X, with Diagnosis Y, under thecare of Doctor Z, seen in 2012.

Datasets/reports: a, b, c

Scope of data: Data from Hospital A, Diagnosis Y, 2009.

A simple practical example might be a doctor who wants to review whathappened to a set of his patients who were previously treated at anotherhospital. That other hospital could allow him to look at only the datafrom 2009 for those patients. i.e. under this role the Doctor/user canreport on all males admitted to hospital X and treated by Doctor Z in2012; they can view whatever datasets are specified; but only view thosedatasets insofar as they were collected previously in a differenthospital during a different timeframe.

All reports which could expose protected health information have an“Apply Safe Harbor de-identification” option which applies§164.514(b)(2) of the HIPAA Privacy Rule. For example, this is shown inFIG. 14, wherein the “Apply Safe Harbor de-identification” is selected.If users are not authorized to access PHI, this option is locked ordisabled so they always view de-identified information. This is shown inFIG. 15 where “Apply Safe Harbor de-identification” option is notselectable.

In addition, each role has a specified minimum group size whichrestricts the minimum number of individuals that users are allowed toreport on. It should be understood that any privacy rule can be setdepending on the jurisdiction(s) in which the system is operating or theprivacy requirements of the system. The aforementioned HIPAA PrivacyRule is simply a well-known example in the US medical field.

The following describes an example of the implementation of therestricted view security feature of the present teaching.

This example system contains three datasets:

-   -   Tumor registry—generic but within the registry, there are        specific data items for breast cancer    -   Tissue typing database is generic. There are research datasets        specific to BC patients.    -   Demographics—containing both identifiable patient details and        more general characteristics, such as gender and ethnicity.

There are three roles used; an administrator, a breast cancer researcherand a melanoma researcher. While an individual may work on bothprojects, they can only access data for the project they are working onat the time, which is specified at log in.

TABLE 1 View Restrictions Role Breast Cancer Melanoma View ResearcherResearcher Admin Tumor registry ✓ x Tumor registry + breast cancer ✓ xdetails Tissue typing ✓ x Tissue typing + breast cancer ✓ x researchDemographics x Demographics (de-identified) ✓ ✓ x

From table 1, as a utility role, the administrator has no access toclinical data. Similarly, as neither group of researchers is authorizedto access PHI, they only have access to the de-identified version.

TABLE 2 Role Configuration Role Breast Cancer Melanoma ApplicationResearcher Researcher Admin Administration ✓ Group Manager ✓ ✓ IdentityCheck All the Answers ✓ ✓ Trends ✓ ✓ Visits ✓ ✓ Clinical Observations ✓✓ Data Export

In this scenario of table 2, nobody is authorized to access PHI, soaccess to applications that provides it is also restricted.

Base groups for the roles are set up as follows:

Base group definition (Breast Cancer Researcher): All patients who havethe “Breast Cancer” flag set in their Demographics view.Base group definition (Melanoma Researcher): All patients who have the“Melanoma” flag set in their Demographics view.

The Demographics view described here is similar to any other viewassociated with a patient (so could be View A 1301 in FIG. 13). In thisscenario, one of the data items in this view has a term equivalent to“Is this patient in the melanoma research group?” to which the answerswould be “Yes” or “No”. This can then be used as one of the criteria forgenerating a group, meaning that only patients where the answer to “Isthis patient in the melanoma research group?” is yes, will be includedin the group. This group can then be used as a base group.

With the base groups configured in this way, it will appear to peoplewith the “Breast Cancer Researcher” role that the only patients in thesystem (and therefore the only patients who will appear in any reports)will be breast cancer patients. For example, FIG. 6 shows two reports603 and 604 but a user's view of these reports is based on the role ofthe user. Viewing each of these reports by different users each assigneda different role would likely result in the users being presented withtwo very different views of this report.

With reference to FIG. 16, there is described a more specificimplementation of the above outlined features. In particular a profileprocessor is provided that facilitates the input and output of queriesand data to the interface database 102 according to specificrequirements of information security and user authorization. The profileprocessor is adapted to allow or restrict different views or profiles ofthe data stored in the database according to the individual user, orrole of the user. It should be understood that the profile processor isgenerally implemented in software as part of a complete databasemanagement system. Alternatively, the processor can be implemented inhardware using programmable electronic gate circuitry (e.g. uncommittedlogic arrays or ASICs) and dedicated volatile and non-volatile memory.

In the present teachings, it has been recognised that the expression I₁to I₁₅ encoded in the expression set table 530 and in the entity historytable 520 (or a combination thereof) can be used not only for matchingagainst a query expression comprising a selection of deterministic andnon-deterministic characters, but also for deploying a set of profileexpressions, also each comprising a selection of deterministic andnon-deterministic characters, that can be used to control the output anddisplay of search results according to the individual user.

The profile processor 1601 effectively acts as a filtration stage inconjunction with a query processor 1602. Preferably, the query processoris also implemented in software. A user input 1603 provides a queryexpression 1604 comprising a selection of deterministic characters andnon-deterministic characters “#”. With reference to FIGS. 7-9, thiscorresponds to the user selection of a plurality of criteria as shown inthe screenshots of these figures. Records (results of scanning with thequery expression) will be extracted from the entity history table 520 bythe query processor 1602 whenever a match of every deterministiccharacter in the query expression 1604 matches a correspondingdeterministic character in the expression field 526 of the entityhistory table 520. Extracted records will be passed through to theprofile processor stage 1601.

The profile processor 1601 obtains a series of user profile expressions1605 from a user profiles database 1606, according to the identity of auser logged into the system, or according to the role of user loggedinto the system. It will be appreciated that the use of user profilesdatabase 1606 allows permissions to be set on roles which are thenassigned to users. As previously mentioned, roles are created andmanaged via the GUI 101. Each of these user profile expressions 1605comprises a set of deterministic characters and nondeterministiccharacters. The user profile expressions define deterministic fields ofthe expressions extracted by the query processor that must match theextracted records in order to allow the record to be passed through tothe display. In the preferred embodiment, the set of user profileexpressions 1606 filter the extracted records on a Boolean OR basis,i.e. for each extracted record there must be a match with at least oneof the user profile expressions. It will be understood, however, that analternative record filtration basis would be to filter the extractedrecords on a Boolean AND NOT basis, i.e. for each extracted record,there must be no deterministic character matches with any user profileexpression. In this case, the user profile expressions would defineareas of the database to be excluded.

As an illustration, there may be five general classes of views. A“discipline view” may be provided for each user discipline, such as“nurse”, “doctor”, “hospital administrator”, etc. These views willfilter for different sets of data, according to the requirements of thediscipline. Similarly, a “specialist view” may be provided for eachsub-group of the disciplines, e.g. the class “doctor” may have optionalspecialist views of “cardiac specialist”, “ENT specialist” etc in whichdifferent levels of detail of information are filtered by the profileprocessor. Another class of view, the “perspective view”, may presentthe same essential information, but use a different sub-table thenatural language terms-a perspective view for separate groups ofpersons, such as “doctor” and “patient” can be provide so that eachclass of person can see the data presented in a comprehensible format.

Note that although the illustrative embodiment shows the query processoras the first record extraction stage from entity history table, and theprofile processor as the second stage, it will be understood that thesetwo operations could be reversed, although this would be very much lessefficient.

In summary, the above described database system and graphical userinterfaces provide numerous advantages over the prior art. Informationof the database is stored in such a manner that data for a query may beextracted far more rapidly than relational database storage schemas, andwith an expression for each extracted record. The presence of thisexpression in the query result has an important effect. A uniquereporting benefit gained is the scope for progressive and complexquerying. The reporting or querying benefit allows a graphical userinterface with an array of user selectable criteria to be provided tothe user such that complex and progressive queries can be easilyperformed.

When a database query is executed to provide information for a report,the answer will be made up of a number of expression records. Thissubset of expressions inherits all the structural information held inthe main expression set.

It will be understood that the database querying essentially requiresbyte wide comparison of the expressions I₁ to I_(n) (I₁ to I₁₅ simplyused as an example above). An extremely fast coprocessor ASIC could thusbe manufactured which includes up to n eight-bit comparators inparallel. In practice, querying would never require all fifteen bytes tobe compared, as most queries involve the setting of a large number ofthe bytes to a non-deterministic state, thus in practice requiring fewerparallel circuits and enabling simplification of the design of adedicated co-processor. This allows near instantaneous results at thegraphical user interface.

While it is not intended to limit the present teaching to any onespecific arrangement it will be appreciated that multiple types ofqueries that were heretofore difficult to generate in a simple userinterface may now be provided. For example it is possible toprogressively generate a plurality of queries to extract data from thedatabase, a first query providing a subset of the plurality of unique,multi-character expressions, the subset being used to create a datasetin a results table for interrogation by a second query. Anotherarrangement is generating a user query in the form of a syntacticallycorrect statement, the database system being configured to interrogatethe user query and transform the user query to identify one or more ofthe plurality of unique, multi-character expressions which satisfy thequery. A further arrangement may provide storing a plurality ofindividual unique, multi-character expressions having data related to aspecific person and parsing the plurality of unique, multi-characterexpressions to extract information not wholly stored in any one of theunique, multi-character expressions. Another arrangement may providestoring a plurality of individual unique, multi-character expressionshaving data related to a specific event and parsing the plurality ofunique, multi-character expressions to extract information not whollystored in any one of the unique, multi-character expressions and definedwithin a queried data window.

In addition, although not described in detail in the present applicationthe graphical user interface also allows a user to input records to thedatabase.

It is also possible in accordance with the present teaching to provide acontrolling of the output of a display of search results according to“event views” and “key views” or indeed to provide a profile of a userof the system and then controlling the output of display of searchresults according to the individual user.

While it is not intended to limit the present teaching to any onespecific implementation it will be appreciated that the architecture istypically a distributed architecture where the database is provided as acloud database.

The words “comprises/comprising” and the words “having/including” whenused herein with reference to the present invention are used to specifythe presence of stated features, integers, steps or components but doesnot preclude the presence or addition of one or more other features,integers, steps, components or groups thereof.

The present teaching is not limited to the embodiments hereinbeforedescribed but may be varied in both construction and detail.

1. A method of querying a database system, the database systemcomprising at least one database populated with a plurality of unique,multi-character expressions associated with the data entities of the atleast one database, the method comprising: providing a graphical userinterface for receiving at least one input selection from a userdefining a database query expression; scanning the at least one databasewith the database query expression to obtain a first set of results;parsing the first set of results with a user profile expressionassociated with the user to obtain a second set of results, the userprofile expression comprising a unique, multi-character expression; anddisplaying the second set of results in the graphical user interface. 2.The method of claim 1 wherein the user profile expression defines a roleof the user and associated permissions.
 3. The method of claim 2 furthercomprising providing a display at the graphical user interface thatpresents the user with at least one role for selection.
 4. The method ofclaim 3 further comprising creating a role associated with the user. 5.The method of claim 4 wherein creating a role comprising selectingpermissions for the role at the graphical user interface which modifiesbytes of the user profile expression to define the role associated withthe user.
 6. The method of claim 4 wherein creating the role comprisingsetting permission for the role such that the role has an associatedbase group and set permissions limit the user to viewing data onindividuals in the base group.
 7. The method of claim 1, furthercomprising providing an interface database, the interface databasepopulated with a plurality of unique, multi-character expressionsassociated with data of the at least one database.
 8. The method ofclaim 7, wherein a data query expression comprises characters whichcorrespond to the expressions stored in the interface database, thecharacters of the data query expression including deterministiccharacters and non-deterministic characters.
 9. The method of claim 8,wherein performing a query comprises parsing the interface databaseusing the data query expression to match the deterministic charactersand ignore the other characters.
 10. The method of claim 9, whereinperforming a progressive query comprises replacing at least onenon-deterministic characters of the data query expression with adeterministic character and scanning a portion of the interface databaseidentified by a result of a previous query using the modified data queryexpression.
 11. The method of claim 1 wherein the at least one databasecomprises a plurality of databases.
 12. The method of claim 11 whereinat least two of the plurality of databases differ in their databasemanagement system, each database management system defining a set ofprograms that enable a user to store, modify, and extract informationfrom the respective database.
 13. The method of claim 12 furthercomprising using the interface database to allow a user to access datastored in the plurality of databases without using the databasemanagement system specific to the plurality of databases.
 14. The methodof claim 12 wherein the database management systems are selected fromone or more of those provided by Oracle, FoxPro, IBM DB2, Linter,Microsoft Access, Microsoft SQL Server, MySQL, PostgreSQL and SQLite.15. The method of claim 7 further comprising converting the data storedin the at least one databases into unique, multi-character expressionsfor storage in the interface database.
 16. The method of claim 15comprising iteratively accessing data within the at least one databaseto convert data not already converted and stored as unique,multi-character expressions in the interface database to unique,multi-character expressions for storage in the interface database. 17.The method of claim 16 comprising updating the interface database on adetermination that one of the plurality of databases has been updated.18. A database system comprising: at least one database populated with aplurality of unique, multi-character expressions associated with thedata entities of the at least one database; and a graphical userinterface for receiving at least one input selection from a userdefining a database query expression; wherein the database system isconfigured to scan the at least one database with the database queryexpression to obtain a first set of results; parse the first set ofresults with a user profile expression associated with the user toobtain a second set of results, the user profile expression comprising aunique, multi-character expression; and display the second set ofresults in the graphical user interface.
 19. The database system ofclaim 18 further configured to perform the steps of any one of claims 2to 17.